PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 3/USEnet 3.084

Internet Message Format | 1988-04-08 | 24.1 KB | [TEXT/ttxt]

Date: Fri 16 Oct 87 19:09:27-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V3 #84

Usenet Mac Digest     Friday, October 16, 1987       Volume 3 : Issue 84

Today's Topics:
     Re: Poor Mac Design Philosophy
     Re: Possible LSC improvements
     Re: Intermail owners take note/Intermail buyers should read
     Re: Poor Mac Design Philosophy
     Re: editing default window size
     Re: Hypercard
     Re: Warning: use of "Pyro" and Opcode's MIDIMAC Sequencer
     Optical Design programs for the Mac ????
     Re: What does access memory manager' mean?
     Re: Simple Hypercard question
     Re: INIT 31 should be enhanced!
     Re: Circuit board layout with penplotter output for Mac?????
     Sony 1302 Monitor Adjustments
     Curses emulation for Mac
     Re: Hypercard again (radio button)
     Re: dialogues during boot?
     KMAPs and KCHRs
     Looking for Common Lisp for the Mac
     Bug in Microsoft EXCEL Square Root
     NetTrek, MazeWars, and Zones
     Re: Mac II Production Stopped?

----------------------------------------------------------------------

From: [e-mail] (Andrew V Jewell)
Subject: Re: Poor Mac Design Philosophy
Date: 13 Oct 87 11:52:32 GMT
Organization: Center for Automation Research, Univ. of Md.


The finder has a SPECIAL menu right? So, why doesn't it include items
like
   REBUILD DESKTOP and
   RESET PARAMETER RAM

It seems this would be amazingly easy to implement, easier to document
and N times more mac-like


                                 Andy Jewell



           Am I missing something obvious here or what?


------------------------------

From: [e-mail] (Robert Gardner)
Subject: Re: Possible LSC improvements
Date: 13 Oct 87 17:35:50 GMT
Organization: Philips Research Labs, Sunnyvale, California

The RAM cache sure gets a lot of bad 'press'. I have used it with LSC
very happily for a LONG time and have survived MANY crashes with it with
absolutely NO loss of data. There was a lot of scare about it for awhile
because it's not write-thru. I don't have any official dope on this, but
from what I have been able to discover (mostly by just watching disk
activity), the cache is flushed to disk whenever FlushVol() is called.
If this is true then the RAM cache is no less safe than any- thing else
since the normal disk buffers are also only flushed when FlushVol is
called. IM recommends that you call FlushVol whenever you close a file
or after a Save, and I suspect LSC does this before Running your
application. (I have LSC set up to do auto saves before a Run.) I
believe ExitToShell and perhaps a few other routines also call FlushVol.

In summary, I have yet to figure out why the RAM cache is more dangerous
than the standard Mac disk-buffering. I have used it successfully for
nearly a year now and have never lost data because of it, though I've
crashed many, many times in many strange and interesting ways.

Robert Gardner


------------------------------

From: [e-mail] (Richard Siegel)
Subject: Re: Intermail owners take note/Intermail buyers should read
Date: 14 Oct 87 00:19:44 GMT
Organization: THINK Technologies, Inc., Bedford, MA

    It is true that we don't site-license InBox (or any of our other
products for that matter), however, we do offer quantity discounts on
our various products. I don't know the terms exactly (I'm customer
support for compilers :-)), but if you call Ellen Neavitt at
1-800-64-THINK she will give you the details. And mention my name when
you call... :-)

>
>Is there anyone from Inbox out there who will take pity on a distraught
>person who, besides his own research work, manages a network of 32 Macs, a
>couple file servers, gateway boxes, and on and on.

    InBox version 2.0 will work concurrently with AppleShare and TOPS, and
also works nicely with bridges (we have two Message Centers with two
Hayes InterBridges) and with all flavors of Macintosh and network (our
net is PhoneNet based).

        --Rich

**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies, Inc).

* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer    *
* Customer Support  | [e-mail]                *
* THINK Technologies, Inc.  (No snappy quote)                       *

------------------------------

From: [e-mail] (Richard Siegel)
Subject: Re: Poor Mac Design Philosophy
Date: 14 Oct 87 00:25:32 GMT
Organization: THINK Technologies, Inc., Bedford, MA

    Because special system-level functions like that are functions that are
only needed in specific conditions, i.e. when the Desktop file gets
trashed or when the Parameter RAM gets corrupted -- these are both
things that in general aren't supposed to happen.

    I realize that for a Mac Hacker these functions are handy, but for a
novice user they would be only confusing and somewhat threatening.

>It seems this would be amazingly easy to implement,

    This is true, but see above.

>easier to document

    Easier to document than WHAT? It's equally trivial to document either
type of function.

>and N times more mac-like

    Again, more Mac-Like than what? The Finder is a program that has no
analog anywhere in the personal computer industry. True, there are
Mac-alike "desktop" things like Windows and GEM, but note what I just
said: the Finder is the prototype for graphical operating-system
interfaces.

>
>                                 Andy Jewell

        --Rich


------------------------------

From: [e-mail] (David Phillip Oster)
Subject: Re: editing default window size
Date: 13 Oct 87 19:29:16 GMT
Organization: School of Education, UC-Berkeley

Apple feels that it is important to let the user choose the settings for
new windows.

If you look at the section of Apple's User Interface Guidlines where
MultiFinder is discussed, you will see that Apple now expects
applications programs to store, with each document, where it was on the
screen. That way, when the user opens the document again, it will show
up on the same place on the screen. (The application has to check that
window size and position are reasonable for the current display, since
the user may have created the file on a machine with a big display and
moved it to a machine with a small display.) The current version of the
Finder does this.

In my programs, I give each of my documents a resource: Type=WIND
ID=128, and update it each time the user saves the file. I'd like to see
this convention catch on.  When the user creates a new document, its
position comes from a resource Type=WIND ID=128 in the program itself.
This resource gets updated whenever the user does a Close or Save. When
the user wants a new window, this window gets used for its initial
position. (If there already is a window on that spot, I adjust the
position of the new window slightly before showing it to the user.)

My newer programs are compatible with networks and multiple users. They
keep special files, called Stationery Pads (as per the tech note on
AppleShare compatiblity) that hold settings like the initial position,
font, size, and even contents of documents. If you open a stationery
pad, you get an new, untitled copy of the pad that is a document. (like
tearing the top sheet off a real, paper pad.)  To change the setting of
a stationery pad, you must explicitly set up a document the way you want
and do a "Save As Stationery Pad."


All of this is detailed in my article: How to Write a TEXT editor, part
II, Data File compatibility, coming soon.

--- David Phillip Oster            --A Sun 3/60 makes a poor Macintosh II.
Arpa: [e-mail] --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu

------------------------------

From: [e-mail] (Paul Molenaar)
Subject: Re: Hypercard
Date: 13 Oct 87 15:55:09 GMT
Organization: Nikhef-K, Amsterdam (the Netherlands).

In article <[e-mail]> [e-mail] (Paul Molenaar) writes:
>I might be mistaken (will check just after I log off... HC hates the
>Switcher) but typing
>
>Show all card fields
>
>in the message box might do the trick. I recall reading something about
>that in the Help Stack.
>
>    Paul Molenaar
>

I was wrong, sorry. I couldn't find a way of showing al card fields.

But I do have another question for the HyperCard public (let's hear it
for a comp.lang.hypercard section! [no moderation plz. Do that in a
comp.lang.hypercard.binaries section ;)])

I added my own cursor to a stack (in fact, I ripped another program :)
and succeeded in bringing it on the screen with 'set cursor to 260' (260
being the id of this cursor). What I would like is that cursor being
shown when the user moves the mousepointer over an information button.
Like: 'if the mouseH > 28 and the mouseV > 36 and the mouseH < 121 and
the mouseV < 130 then set cursor to 260'. This works only partly, as
HyperCard steals the idle time in which I perform this operation. The
cursor is switched between the browse tool and my custom cursor.

Anyone any idea to prevent HyperCard from changing the cursor?


        Paul Molenaar

    "Just checking the walls"
        - Basil Fawlty -

------------------------------

From: rusty@velveeta (rusty wright)
Subject: Re: Warning: use of "Pyro" and Opcode's MIDIMAC Sequencer
Date: 13 Oct 87 21:00:32 GMT
Organization: UC Berkeley Math Department

I had trouble with Pyro on an SE with switcher.  Once I removed Pyro
from the system folder it started working again.

--------------------------------------
    rusty c. wright
    [e-mail] ucbvax!weyl!rusty


------------------------------

From: [e-mail] (Pat Seitzer)
Subject: Optical Design programs for the Mac ????
Date: 13 Oct 87 20:09:39 GMT
Organization: noao

Anyone know of any general purpose optical design programs for the
Macintosh?  I've seen several advertised for the IBM PC, but nothing for
the Mac.

email to me - I'll summarize for the net if any interest (and I
apologize if this has been discussed here recently).

thanks in advance,

Pat Seitzer, National Optical Astronomy Observatories, Tucson AZ, 602-325-9387
UUCP: {arizona,decvax,hao,ihnp4}!noao!seitzer
    or  uunet!noao.arizona.edu!seitzer
Internet: [e-mail]
SPAN/HEPNET: 5356::SEITZER or DRACO::SEITZER

------------------------------

From: [e-mail] (Ed Tecot)
Subject: Re: What does access memory manager' mean?
Date: 13 Oct 87 22:39:57 GMT
Organization: Apple Computer Inc., Cupertino, USA

In article <[e-mail]> [e-mail] (tom lippincott)
writes:
>But wait, there's more!
>
>Even calls that don't change the heap can cause problems -- most quickdraw
>routines, in particular, are not reentrant.  If you make a quickdraw call
>while the main program is making one, you'll probably mess up that call.
>(I've tried this.  The bugs are Mostly Harmless, but there.)

No, that's not true.  What you are experiencing is completely different:

Someone else has already explained that an interrupt can interrupt just
about anything, including heap compaction.  Of course you don't want to
make any memory manager calls at this time, since that could cause heap
corruption. However, you also don't want to reference ANY unlocked
relocatable blocks, as they could be "in transit".

Quickdraw regions are by definition relocatable.  So it follows that you
don't want to make any quickdraw calls that affect regions.  However,
every grafPort contains two regions, a clipRgn and a visRgn.  So, you
don't want to make any quickdraw calls that uses a grafPort.  It turns
out that only two useful calls remain:  CopyBits and CopyMask.  But
beware:  These calls check to see if the destination (pix or bit)Map is
the same as that of the current grafPort, and if so, uses the grafPort's
clipping.  So, in effect, these calls are only useful if the destination
is an offscreen (pix or bit)Map.

In summary, QuickDraw is reentrant, but it's dependency upon the memory
manager precludes its use during interrupt time.

                        _emt


------------------------------

From: [e-mail] (Macintosh Users Group)
Subject: Re: Simple Hypercard question
Date: 12 Oct 87 17:49:17 GMT
Organization: RUNX  Un*x Timeshare. Sydney, Australia.

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>It seems possible to me that Hypercard keeps its startup stack name in a
>resource somewhere. If not, then there are 2 ways that come immediately to

Yes Keith, the STR# resource "Misc", ID=1001, has as it's first string
the name of the startup stack.

Jason Haines, President

Club Mac Macintosh Users Group, Sydney, Australia
Phone Home: [phone]
Snail:      Box 213, Holme Building, Sydney University, NSW, 2006, Australia
ACSnet:     [e-mail]       ARPA:   [e-mail]
UUCP:{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.ips.oz!clubmac

------------------------------

From: [e-mail] (David B. Wollner)
Subject: Re: INIT 31 should be enhanced!
Date: 14 Oct 87 03:56:47 GMT
Organization: U.C. San Diego

Before everyone starts debating the "correct" way of enhancing INIT 31,
it seems that a new init from CE Software should solve the problem.  Its
name is AASK. It brings up a list of inits in the system folder, and
allows the user to choose which to run.  I have not had a chance to play
with this one, so treat it as a rumor until you talk to CE software.

    CE Software
    801 73rd St.
    Des Moines, IA 50312
    [phone]

As per usual, I have very little relationship with reality, let alone
this company.

    - dbw


------------------------------

From: [e-mail] (Teriann Wakeman)
Subject: Re: Circuit board layout with penplotter output for Mac?????
Date: 13 Oct 87 17:04:49 GMT
Organization: HP Corporate Engineering - Palo Alto, CA

Your best bet for getting the Mac to plot is with a HP plotter (RS232
option for small plotters and any of the big plotters). The best plotter
driver currently available is MacPlotts II from Computer Shoppe in
Greensboro N.C.. has routines for pen changes (read colours). I have
been using MacPlottsII with various HP plotters for about 2 years now (I
use a 512K Mac at work), and have forund it to be an exellent
application. The manual could use some help, but phone call have always
produced cuterous fast help.

I have no connection with Computer Shoppe other then as a satisfied
customer and have a connection with HP plotters via a profit sharing
check (buy them HP plotters- good products!!)

TeriAnn Wakeman HPMUG co-ordinator


------------------------------

From: [e-mail] (Richard Siegel)
Subject: Sony 1302 Monitor Adjustments
Date: 14 Oct 87 14:06:25 GMT
Organization: THINK Technologies, Inc., Bedford, MA

Well, thanks to info sent to me from the net, I've been able to adjust
my Sony 1302 color monitor so that the shimmering is gone and the edges
are no longer bowed inward. The problem is that the color focus is
wrong; a white line looks as if it's split into a red line and a blue
line, and the red seems to be to the left.

There doesn't seem to be an adjustment on the circuit boards; however,
there are magnets on the yoke that adjust the focusing; are these where
I want to do the adjusting? Will I get toasted if I try to adjust the
color focus on the CRT?

Does anyone know how to fix this color problem?

Thanks in advance...

        -_Rich


------------------------------

From: [e-mail] (Jay Norwood)
Subject: Curses emulation for Mac
Date: 13 Oct 87 21:16:00 GMT
Organization: Motorola Inc. Austin, Tx

moving some c programs from a Sun.  It is not apparent from the Inside
Macintosh volumes how to hilite characters. Jay Norwood


------------------------------

From: [e-mail] (Bill Faulkner)
Subject: Re: Hypercard again (radio button)
Date: 12 Oct 87 16:54:15 GMT
Organization: Natl Ctr Atmospheric Research, Boulder, CO

In article <[e-mail]>, [e-mail] (Jan Harrington) writes:

> How you handle the highlighting depends on whether you've checked Auto hilight
> when you defined the button.  If Auto hilight is checked (in that dialog box
> you get for buttons), then Hypercard will take care of turning the button on
> and off.  You can check the button's state with something like:
>
>     if autoHilite of button ID XX is true then
>         .....
>
> Replace the XX, of course, with the right button ID or ID XX with the button's
> name if the script is attached to something other than the button itself.  If
> the script is attached to the button itself, then you don't need the button
> identifier.

What you said is true, however, you are misleading people.  Both hilite
and autoHilite are properties of a button, but they are vastly
different. Checking the state of autoHilite, tells you nothing about the
button being "on"


> If Auto hilight isn't selected, then you must attach a script to each button
> which detects mouseup events, checks the current hilite state, and then sets
> the button accordingly:
>
>     if hilite is true then
>         set hilite false
>     else
>         set hilite true
>     .....
>
> In most cases, using Auto hilite is certainly easier!

NO NO NO NO!  You don't understand radio buttons at all! If you click on
a hilited radio button it should remain on.  And for radio buttons,
Autohilite is NOT the way to proceede.  I know, because I have developed
a stack that uses radio buttons.

Now to answer Chuq's question about how to develop radio buttons.

First, create the set of buttons that you want to use as a set of radio
buttons and organize them in a logical manner.  Set the Autohilite to
off and show name to on.  Say you have five buttons numbered 1-5.  The
script for button number 1 would be like this:

on mouseUp
  set hilite of button 2 to false
  set hilite of button 3 to false
  set hilite of button 4 to false
  set hilite of button 5 to false
  set hilite of button 1 to true
  --
  --  do what ever this button is supposed to do
  -- end mouseUp

The other 4 buttons would proceed in a similar fashion, with the script
of button n that turns the hilite of button n to true and all the others
to false.  This will give you the action of standard "radio buttons".
Also note, that due to personal prefence, I will set the hilite of
button n to true after all the other button hilites are set to false.
This is to prevent seeing 2 radio buttons checked at the same time,
although this time is rather small.  I would rather buttons hilited for
the split second it takes to change all the button's states.

True, it is not the most elegant solution to the problem, but it is what
you are stuck with, since hypercard doesn't know about radio buttons
other than they are just another button style.

        Bill
--
Bill Faulkner * NCAR (Nat'l Center for Atmospheric Research)
PO Box 3000 * Boulder, CO  80307-3000 * 303-497-1259
UUCP:  [e-mail] or  ..!hao!scdpyr!faulkner
INTERNET: [e-mail]  ARPA: [e-mail]


------------------------------

From: [e-mail] (Brian Rauchfuss)
Subject: Re: dialogues during boot?
Date: 12 Oct 87 15:29:16 GMT
Organization: Hewlett-Packard - Fort Collins, CO


    Why don't you want to clear the startup screen? Anyways, I remember
stepping through some code that did that once and they did all their
drawing without the higher managers, just quickdraw.  They drew their
window with lines, and tested their buttons with PtInRect.

    Brian Rauchfuss


------------------------------

From: [e-mail] (D. Ranson CNET)
Subject: KMAPs and KCHRs
Date: 13 Oct 87 09:57:56 GMT


(Before you ask: Yes, I have read TechNote 160)
 How are KMAP ressource REALLY used in System4.1? On a SE, I have found
that KMAP ID 1 in the System file is actually used (You can easily swap
2 keys), but the Keyboard DA apparently assume a default KMAP. On a
Plus, KMAPs seem to have no effect at all. You can boot from a System4.1
without any KMAP in it! Are KMAPs only for ADB keyboards? Why this
limitation? I suppose the right KMAP is chosen at boot time by comparing
some sort of keyboard ID to the ressource ID. Any info on that? We
French Mac-ers are particularly interested in KMAPs because of a bug in
the "physical mapping" of our keyboards. The raw codes for the keys <
and ` have been swapped between the Plus and the ADB keyboards. Only
KMAPs can cure that if you want a universal System file (Currently, the
recommended System file for a Plus in France is 3.2).
    Daniel Ranson
    ...!seismo!mcvax!inria!{crcge1 or cnetlu}!ranson


------------------------------

From: [e-mail]
Subject: Looking for Common Lisp for the Mac
Date: 13 Oct 87 18:51:00 GMT


Help!!!

I'm looking for the best implementation of COMMON LISP for the the
Mac-Plus. Any -->'s appriciated.

Dave Tcheng


------------------------------

From: [e-mail] (William H. Jefferys)
Subject: Bug in Microsoft EXCEL Square Root
Date: 14 Oct 87 14:14:35 GMT
Organization: U. Texas, Astronomy, Austin, TX

I have run across a bug in the Microsoft Excel square root function. I
am using Microsoft Excel v. 1.04 on a Mac+. When taking square roots of
numbers in the range [0.999975,0.99999991] I find that there is  a
significant error. The error is discontinuous at the left end: if the
argument is only 0.999964, the error drops suddenly to zero.

To illustrate this I have made up a table with the following columns: In
the first column, x. In the second column, u=1-x*x; in the third
column, y=sqrt(u), calculated with the Excel square root function. In
the  fourth column, x*x+y*y-1 (should be zero). The calculation was done
in Full Precision mode.

In the fifth column I performed a single Newton-Raphson iteration
starting with y, to get a better approximation y' to the square root.
The sixth column is the same as the fourth column, but calculated using
the result of the  Newton-Raphson iteration. The error is much  smaller.

  x     u=1-x*x     y=sqrt(u)      x*x+y*y-1    y'=(y+u/y)/2   x*x+y'*y'-1

0.0001 0.99999999 0.999999995      0          0.999999995       0
0.0003 0.99999991 0.999999955      1.9984E-15 0.999999955      -1.11E-16
0.0005 0.99999975 0.999999875      1.5543E-14 0.99999987499999 -1.11E-16
0.0008 0.99999936 0.99999968       1.0258E-13 0.99999967999995  2.22E-16
0.001  0.999999   0.9999995        2.5002E-13 0.99999949999987 -1.11E-16
0.002  0.999996   0.999998         4.0001E-12 0.999997999998    0
0.003  0.999991   0.9999955        2.025E-11  0.99999549998987  0
0.004  0.999984   0.999992         6.4002E-11 0.999991999968    0
0.005  0.999975   0.9999875        1.5625E-10 0.99998749992187  0
0.006  0.999964   0.999981999838   0          0.999981999838    0
0.007  0.999951   0.99997549969987 0          0.99997549969987  0

This seems to be a Microsoft bug and not a ROM bug, because the same
calculation done in Lightspeed C (which uses SANE) does not produce this
error. Microsoft apparently has their own private square root routine in
EXCEL, and didn't use SANE. Too bad.

Until this is fixed in (I hope) Version 1.05 (*please*, Microsoft!!!),
I recommend using the following macro function SQRTF instead of SQRT:

function  SQRTF
          =RESULT(1)
          =ARGUMENT("in",1)
          =SET.NAME("out",SQRT(in))
          =IF(in<>0,SET.NAME("out",0.5*(out+in/out)))
          =RETURN(out)

If anyone is interested I can send them the Binhexed spreadsheet. It's
about 4K long.

Bill Jefferys


------------------------------

From: [e-mail] (Andy J. Williams)
Subject: NetTrek, MazeWars, and Zones
Date: 12 Oct 87 19:52:08 GMT
Organization: Dartmouth College, Hanover, NH

Does anyone know of a patch or a way of creating a patch so that
NetTrek, Mazewars+ et al (any appletalk game) can work accross zones on
an Appletalk network?

--Andy

--
Disclaimer: You better like my opinions, my mother can beat up your mother...

Andy J. Williams                               [e-mail]
vive spam and borscht!                  {ihnp4,decvax,linus}!dartvax!borscht


------------------------------

From: [e-mail] (Joel West)
Subject: Re: Mac II Production Stopped?
Date: 14 Oct 87 13:55:38 GMT
Organization: Palomar Software, Inc., Vista, CA

I heard a rumor that there will be a new ROM in a month or two. No
reading on its accuracy.
--
    Joel West  (c/o UCSD)
    Palomar Software, Inc., P.O. Box 2635, Vista, CA  92083
    {ucbvax,ihnp4}!sdcsvax!jww     [e-mail]
So. California: where the ground does the Rocking 'N Rolling for you

------------------------------

End of Usenet Mac Digest
************************